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ABSTRACT 

Simulation of spacecraft on-orbit operations is discussed in reference to Martin 
Marietta's Space Operations Simulation laboratory's use of computer software models to 
drive a six-degree-of-freedom moving base carriage and two target gimbal systems. In 
particular, key simulation issues and related computer software models associated with 
providing real-time, man-in-the-loop simulations of the Manned Maneuvering Unit 
(MMU) are addressed with special attention given to how effectively these models and motion 
systems simulate the MMU's actual on-orbit operations. 

THE WEIGHTLESS EFFECTS of the space environment require the development of entirely 
new devices for locomotion. Since the access to space is very limited, it is necessary to 
design, build, and test these new devices within the physical constraints of earth using 
simulators. The simulation method that is discussed in this paper is the technique of using 
computer software models to drive a Moving Base Carriage (MBC) that is capable of 
providing simultaneous six-degree-of-freedom motions. This method, utilized at Martin 
Marietta's Space Operations Simulation (SOS) laboratory, provides the ability to simulate 
the operation of manned spacecraft, provides the pilot with proper three-dimensional visual 
cues, and allows training of on-orbit operations. The most effective use of this capability 
has been in designing, testing, and operational training of the Manned Maneuvering Unit 
(MMU). ~ 

To properly evaluate the operation of a spacecraft and provide the pilot with the 
necessary training to operate it with confidence, accurate modelling of both the functional 
operation of the spacecraft and the physical laws that govern its operation are necessary. 
Due to limitations in the ability to model all aspects of a spacecraft and the space 
environment, limitations in finances to program these models, and limitations in the amount 
of computer code that can be executed in a finite amount of time, it is not feasible to model 
each variable that might affect a spacecraft's operation. Therefore, modelling is limited to 
those variables that are likely to have a significant effect on the spacecraft's operation. Once 
the modelling is complete, it is necessary to evaluate the level of simulation system fidelity, 
as compared to actual on-orbit operations, and to determine where the simulation needs 
improvement. 

The purpose of this paper is to discuss significant MMU simulation issues, the related 
models that were developed in response to these issues and how effectively these models 
simulate the MMU's actual on-orbit operations. 

MAWED MANEUVERING UNIT 

The MMU was designed for untethered astronaut extra-vehicular activity (Figure 1). It 
is a self-contained vehicle, comprised of electrical power systems, propulsion components, 
controls, and displays necessary for on-orbit flight operations. The MMU utilizes 
pressurized gaseous nitrogen, expelled through 24 fixed thrusters, to achieve six-degree- 
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of-freedom maneuverability. Attitude and directional motion commands are input through 
two hand controllers. The left hand controller is used for translational commands (X, Y, and 
Z) and the right hand controller is used for rotational commands (Roll, Pitch, and Yaw). 
The hand controllers generate electrical signals that are processed by two independant 
control electronics assemblies, which then send thruster firing commands to the 
appropriate thrusters. The unit is fully redundant such that no single credible failure can 
prevent a safe return. 

A button on the rotational hand controller allows initiation of Automatic Attitude Hold 
(AAH), which uses three rate integrating gyros to maintain the MMU inertial attitude in any 
combination of rotational axes. To provide mission flexibility, two standard control modes 
are available: Normal mode, which is used for all operations of the MMU alone; and Satellite 
Stabilization mode, which is used for operations when the MMU is attached to a satellite or 
other massive payload. Satellite Stabilization mode uses an alternate thruster select logic to 
compensate for the induced large moments of inertias and the center-of-mass offset, to 
provide increased rotational control authority, and to minimize plume impingement of the 
payload. 

SMULATION SYSTEM 

HARDWARE - The simulation system is driven by a Gould 32/9750 computer, that 
contains software models necessary to simulate spacecraft operations. The output of these 
software models provide input to a General Electric Series Six digital servo system. This 
system controls DC servo motors that provide motion to the simulation hardware. Sensors 
on this hardware return information to the servo system to verify their position and rate. 
The entire system is classed as a second-ordered, hybrid control system (see Figure 2). 

The primary piece of simulation hardware is the man-rated, six-degree-of-freedom 
MBC (Figure 3) that moves within a cartesian coordinate system. This device provides 
translational motion and rotational motion, along and about the three axes simultaneously. 
In addition to the MBC, a Single-Axis Gimbal (SAG) and a Three-Axis Gimbal (TAG) (Figure 
4) are used. These gimbals allow the pilot to approach and attempt docks to rotating targets. 
The SAG provides one-degree-of-freedom motion in rotation for large full-scale target 
mockups, whereas the TAG provides three-degrees-of-freedom motion in rotation for small 
full-scale and partial-scale target mockups. Because the SAG and TAG are not capable of 
translational motions, these motions are compensated for by the MBC. 

For MMU simulations, an MMU mockup is attached to the gimbal head of the MBC 
(Figure 3). The only functional hardware present on this mockup are those interfaces 
necessary for the pilot to provide input to the system, such as handcontrollers and switches, 
or to receive system information, such as gauges and lights. 

SOFTWARE - Software models are responsible for all aspects of the simulation system. 
These models simulate MMU electronics, MMU propulsion systems and the physical laws of 
space that govern the MMU's operation, and control of the simulation system and data 
recording. The control of the simulation system and data recording will not be discussed in 
this paper. The simulation of the MMU electronics, propulsion systems, and physical laws 
of space that govern the MMU's operation were divided into the following four general 
software modules: 

MMU Electrical Control and Switching (ECS) - Monitors all MMU switches, detects 
changes in switch settings, controls switch malfunctions as initiated by the simulation 
run coordinator, and passes this information to other modules. 

MMU Control Electronics Assembly fCEAl - Accepts handcontroller inputs (X, Y, Z, 
Roll, Pitch, and Yaw), MMU configuration and control modes, modelled gyro rates, and 
MMU CEA malfunctions as initiated by the simulation run coordinator. The output from 
this module specifies which of the MMU’s twenty-four thrusters should be fired. 

MMU Propulsion - Models the propulsion system, thruster firing times, manifold 
and regulator pressures, propellant use as a function of thruster firing time, and MMU 


propulsion malfunctions as initiated by the simulation run coordinator. Output from 
this module specifies fuel consumption and which thrusters were actually fired. 

MMU Dynamics - Models dynamic performance of flight hardware in zero-g 
environment. Includes associated center-of-mass offsets, forces, moments, orbital 
mechanics, flexible body dynamics, MMU plume impingement effects, vehicle/target 
relative motion, and two-body contact dynamics. Output from this module is returned to 
the CEA module to provide gyro rate information and to the digital servo system to 
provide position commands for the servo mechanisms. 

Modelling all aspects of the simulation through software allows for complete flexibilty 
to modify any part of the simulation system. This provides the ability to simulate the 
operation of the MMU either in orbit or free space, start the simulation with any set of 
initial conditions desired, select the appropriate models, and insert up to three simultaneous 
malfunctions from a list of over two hundred possible choices. 

SIMULATION ISSUES 

In order to develop a valid simulation, it is necessary to assess a wide variety of issues. 
The first step is to identify which issues will not produce a noticeable effect on the 
simulation. For example, the SOS lab does not simulate atmospheric effects, the effects of 
gravity between the earth and sun or between the earth and moon, the effects of the non- 
spherical shape of the earth, and the effects of non-circular orbits. The next step is to 
determine which issues, of those that do produce a noticeable effect on the simulation, can be 
simulated to a high degree of fidelity within the scope of the present simulation system. In 
the MMU simulation, these include the ECS, CEA, propulsion system, forces, moments, 
orbital mechanics, and vehicle/target relative motion. Those issues that remain cannot be 
simulated to the degree of fidelity desired. This is due to either simulation system 
limitations or lack of sufficient knowledge of the issue. The remainder of this paper 
discusses some of these simulation issues and the on-orbit experiences related to them. 

CENTER-OF-MASS OFFSET - Center-of-mass offset refers to a condition where the 
center-of-mass and center-of-thrust are not co-located. This results in translational 
commands inducing rotational motions. 

Since the position of the MMU thrusters are fixed, center-of-thrust is simple to locate 
and remains unchanged. However, the center-of-mass is dependant on the relative positions 
of MMU system components; specifically, the MMU, target attachment devices, the pilot’s 
spacesuit, and the pilot’s body. The exact position of the center-of-mass changes, because 
the pilot tends to float inside the spacesuit and is likely to move his arms and legs. Since the 
center-of-mass offset is dynamic, it is not possible to accurately simulate its variable 
effect on the operation of the MMU. However, it is believed that small variances in center- 
of-mass offset should not cause significant differences between the simulation and flight 
hardware operation. Therefore, the anticipated position of the pilot during the majority of 
the flight is defined and used for all simulation operations. 

One instance where this inaccuracy was detectable occurred during mission 41 C when 
astronaut James Van Hoften flew the MMU with his legs forward instead of straight down, as 
had been assumed for simulation training. 

FLEXIBLE BODY DYNAMICS - Flexible Body Dynamics (FBD) is the process in which 
various parts of a body oscillate at different frequencies due to a "forcing function" 
vibration. On the MMU, the primary oscillating components are the main body, the two 
arms, and a docking device (when attached). The primary forcing function is driven by 
thruster firing activity. 

During STS mission 51 A astronaut Dale Gardner used the MMU with the Apogee Kick 
Motor Capture Device (ACD), known as the "stinger", attached to the MMU arms to 
rendezvous and dock with a satellite. During this mission he reported significant 
sluggishness in the lateral command response while operating with AAH active and in 
Satellite Stabilization control mode. He also perceived a higher level of thruster activity in 


AAH and a higher than expected propellant usage, than during the simulated training 
missions. 

Due to this on-orbit experience, a variety of simple MMU FBD models were designed 
and tested to study their effect on the AAH system, including one model that closely 
resembled the on-orbit configuration of Dale Gardner. The data produced by these series of 
analyses indicated that FBD of the entire MMU system negatively affects the AAH control 
system by causing a higher level of thruster activity. This in turn is likely to produce an 
increase in propellant consumption as compared to a totally rigid configuration. As a result, 
a simple FBD model has been added to the simulation. To reduce this effect with the flight 
hardware, it was recommended that the AAH switching lines on the flight hardware be 
widened or removed, and that the MMU not be flown in AAH in Satellite Stabilization mode 
while not attached to a satellite.* 

‘John A. Cuseo, Charles A. Dallas, and David L. Van Duzen, MMU Control System Analysis 
With Flexible Body Modelling (Martin Marietta Aerospace, December 13, 1985), pp. 1- 
32. 


PLUME IMPINGEMENT - Plume impingement refers to the effect of MMU gas plumes on 
nearby objects. The simulation issue is to reproduce accurately the affect that the expelled 
gas will have on the target. As gas is expelled from the MMU thrusters to control its 
position and attitude, the molecules that impinge upon the target will impart forces that will 
alter its present motion. Therefore, it is necessary to train the pilots to minimize plume 
impingement so that they will be able to safely and successfully rendezvous with a target on 
orbit. 

During mission 41 C, unexpected plume impingement effects occurred when astronaut 
George Nelson approached the Solar Maximum satellite. There were approximately 18 cases 
of MMU thruster plumes contacting the satellite surface, causing the satellite to start 
tumbling. This experience resulted in the subsequent modelling of plume impingement 
effects of the MMU. 

The plume impingement effects were modelled by ignoring the minor variances in the 
exterior surface of the target and assuming it to be whatever basic geometric shape it most 
closely resembled. The plume effect for each thruster oriented towards the target was 
calculated and summed to produce a net effect. Because of the large number of calculations 
required to obtain the forces and moments impinging on the target at any given time, all data 
points for a variety of distances and rotational orientations were calculated off-line prior to 
the simulation and stored in a data table. During the simulation, the computer calculated the 
relative position and orientation of the target to the MMU and extracted the three forces and 
three moments from the table that most closely matched the present conditions. 

This method provided a first order approximation of the actual conditions that would 
exist on orbit, because it was not possible to determine the actual translational orientations, 
rotational orientations, and rates of the pilot and target that would exist on orbit during the 
rendezvous. It was also not possible to store a large enough table of data points that would 
allow for minute changes in position and orientation. In addition, the actual commands that 
would be used on orbit would be the result of a wide variety of factors that are 
unpredictable. This rough approximation was acceptable because it was only important for 
the pilot to be aware of the problems that would be caused if large amounts of gas were used 
near the target, not for the pilot to train for impingement of a specific target. This 
modelling was used in training astronauts Joe Allen and Dale Gardner to rendezvous and 
capture the Hughes Westar and Palapa-B satellites during Mission 51 A. Because of their 
training, both astronauts reported only minor plume impingement effects on orbit. 

CONTACT DYNAMICS - Contact dynamics between two bodies in space is an important 
issue. If a force is applied to an object in the earth environment, the object may or may not 


move, depending on other forces acting upon it. If a force is applied to an object in space, the 
object moves in a manner directly related to the magnitude and direction of the force applied. 
Therefore, it is necessary to simulate this effect so that the pilot can become accustomed to 
the effects of contact dynamics. The two important areas of the contact dynamics issue are 
contact between the craft and target during capture, and contact while working on a 
spacecraft, such as repairing a satellite. 

When the MMU is used to capture a target, it is possible to provide a relatively accurate 
model of the contact dynamics that exist. This is because the simulation system takes into 
account the relative shapes, positions, orientations, and rates of the two objects involved. 

Contact between the pilot's body and another object is difficult to simulate, because the 
human is an unpredictable and autonomous system. Therefore, it is necessary to obtain 
real-time data that describes the direction and magnitude of the forces being applied to the 
object. Presently, the only feasible method of determining this data is to place load cell 
arrays on all the surfaces of the target that will be involved. The load cell arrays provide a 
direct input of the magnitude and direction of the forces involved. This data can then be used 
to simulate the induced rates caused by the interaction and, in turn, affect the resultant 
motions of both the MMU and target. In a real-time simulation system, it is possible to 
model the relative motions between the pilot and target accurately with this method. This is 
an additional capability that is planned for implementation to the simulation system at a 
later date. 

FRAME RATE - Frame rate refers to how often the digital computer executes the 
necessary software models. This time period is critical when the simulation is operating in 
real-time, because it is necessary to execute the software as often as possible to simulate 
an anolog system. If the frame rate is too large, the hardware devices move in noticable 

steps. 

The frame rate of the SOS lab simulator is 40 milliseconds (1/25 second). Although 
this frame rate has been sufficient, there have been a couple of instances where a higher 
resolution would have been desirable. An example, was when astronaut Bruce McCandless 
indicated that thruster firing activity during STS mission 41 B was much faster than he had 
ever experienced in the simulator. This high level thruster activity was caused by AAH 
responding to rotational rates induced by translational commands. Through analyses, it was 
determined that the discrepency was due to the fact that the simulation frame rate was 
slower than the analog flight hardware. Since the simulator operates in discrete 
increments, it updates these rotational rates only once each frame. Therefore, it is likely 
that as the rotational rates build up, they will approach the AAH switching line (the point at 
which AAH will begin to correct for rotational rates or angles) in one frame and pass beyond 
it by the next frame. The simulation model will then command correcting rates, which will 
build up and take the rotational rates back across the switching line during one frame. This 
lagging response time can result in larger correctional moments and a slower AAH cycle 
time. 

On the analog MMU, correcting rates are commanded as soon as rotational rates pass the 
AAH switching line. As soon as the rates pass back across the switching line, the correcting 
rates are terminated. Because of this quick response time, the appropriate thrusters will 
cycle on and off at a frequency of about 5 Hz until the rotational rates are corrected. 

AAH RATE - The MMU AAH thruster logic utilizes thruster pulsing and continuous 
thruster firing, as necessary, to correct for unwanted rotational rates. The pulsing aspect 
of the logic operates in terms of 8 millisecond pulses, three times a second. Because the SOS 
lab simulation operates at 40 milliseconds, it was necessary to devise a method where the 
net forces produced by a specific command would be equal. Because impulse expended is the 
parameter that determines delta velocity, or in the above case, rotational rate, the net effect 
will be the same as long as the impulse is the same. The solution is found by using the 
relation between impulse, force, and time; I = F * t. If t = 0.008 sec. and F = 1 .7 lb. (7.56 
N) (which is the nominal MMU force for one thruster), I = 0.0136 Ib.-sec. (0.0605 N- 
sec.). By setting t = 0.040 sec. (the simulation frame rate) and keeping I constant, it can 



be calculated that the equivalent 40 millisecond force level is F = 0.34 lb. (1 .51 N). By 
executing the AAH pulsing logic three times each frame and using this force value, the 
resultant effect in MMU motion will be the same as on orbit, even though the simulator is 
operating at a frame rate much slower than that of AAH. 

VISUAL CUES - Close proximity operations between the MMU and a target require full 
three-dimensional visual cues; therefore, it is necessary to provide the pilot with full- 
scale mockups of the targets and the ability to move about them. The associated problem is 
that the MBC operates in a relatively confined area. The information gathered through both 
direct and peripheral viewing of the room provides the pilot with information that would not 
exist on orbit. 

In an effort to reduce the effect of any visual room cues during simulations, the axes of 
the target can be rotated so as to not align with any room edges. This procedure was used 
during training for the Skylab mission and for Cargo Bay mockup operations. In both of 
these examples, the astronauts trained within full-scale mockups; thus, they received 
visual cues from the mockups and not from the room. 

Another visual cue issue arose during STS mission 51 A training. This training involved 
learning how to capture a satellite in which the axis of spin is close to, but not exactly, 
aligned along the axis of capture. This spin effect, known as coning, results in the pilot 
trying to dock with a point that is actually moving in a circle, in reference to himself. 

When the addition of the coning effect to the SOS simulation system was first 
recommended, it was realized that the TAG would not be able to withstand the high inertias 
that would be induced by the satellite mockup. Since only the relative motions of the pilot 
and target were necessary for training, the visual coning effect of the satellite was imparted 
on the MBC. Concerns arose that these MBC motions would result in pilot disorientation or 
sickness. The results of the training simulations using this method demonstrated that the 
MBC motions did not cause any discomfort or disorientation. Subjective pilot comments 
indicated that the visual cues were more predominant than the motions of the MBC. Another 
concern was that the pilots would visually notice, from room cues, that the MBC and not the 
satellite mockup was coning. The pilots reported that they were unaware of this because of 
the high workload involved in performing the task. 

SUMMARY 

A simulation system that provides both developmental analysis data and operational 
training requires a high degree of simulation fidelity. Through comments of astronauts who 
have flown the MMU on orbit, it has been determined that many of the MMU simulation 
issues have been modelled to an appropriate degree of fidelity. These include center-of- 
mass offset, plume impingement, contact dynamics, AAH rate, and visual cues. On the other 
hand, the frame rate and flexible body dynamics issues have not yet been modelled to the 
desired degree of fidelity. 

The use of the SOS laboratory's simulation system has indicated that a high fidelity, 
real-time, man-in-the-loop simulation is feasible and effective. As demonstrated with the 
MMU, the simulation provided a reliable means of training personnel to effectively and 
safely operate on orbit. 
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AAH - 

Automatic Attitude Hold 

PCD - 

Apogee Kick Motor Capture Device 

CEA - 

Control Electronics Assembly 

ECS - 

Electrical Control and Switching 

FBD - 

Flexible Body Dynamics 

MBC - 

Moving Base Carnage 

MMU - 

Manned Maneuvering Unit 




Single Axis Gimbal 
Space Operations Simulation 
Space T ransportation System 
Three Axis Gimbal 
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